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Abstract 


This document describes a method for controlling two specific types 
of Ethernet switching via Generalized Multi-Protocol Label Switching 
(GMPLS). This document supports the types of switching corresponding 
to the Ethernet services that have been defined in the context of the 
Metro Ethernet Forum (MEF) and International Telecommunication Union 
(ITU) G.8011. Specifically, switching in support of Ethernet private 
line and Ethernet virtual private line services are covered. Support 
for MEF- and ITU-defined parameters is also covered. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6004. 
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Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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I; 


Introduction 


[MEF6] and [G.8011] provide parallel frameworks for defining network- 
oriented characteristics of Ethernet services in transport networks. 
The framework discusses general Ethernet connection characteristics, 
Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network 
Interfaces (NNIs). Within this framework, [G.8011.1] defines the 
Ethernet Private Line (EPL) service and [G.8011.2] defines the 
Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both 
service types. [MEF10.1] defines service parameters and [MEF11] 
provides UNI requirements and framework. 


[MEF6] and [G.8011] are focused on service interfaces and not the 
underlying technology used to support the service. For example, 
[G.8011] refers to the defined services being transported over one of 
several possible "server layers". This document focuses on the types 
of switching that may directly support these services and provides a 
method for GMPLS-based control of such switching technologies. This 
document defines the GMPLS extensions needed to support such 
switching, but does not define the UNI or External NNI (E-NNI) 
reference points. See [RFC6005] for a description of the UNI 
reference point. This document makes use of the traffic parameters 
defined in [RFC6003] and the generic extensions defined in [RFC6002]. 


1. Overview 


This document uses a common approach to supporting the switching 
corresponding to the Ethernet services defined in [MEF6], [G.8011.1], 
and [G.8011.2]. The approach builds on standard GMPLS mechanisms to 
deliver the required control capabilities. This document reuses the 
GMPLS mechanisms specified in [RFC3473] and [RFC4974]. The document 
uses the extensions defined in [RFC6002]. 


Two types of connectivity between Ethernet endpoints are defined in 
[MEF 6] and [G.8011]: point-to-point (P2P) and multipoint-to- 
multipoint (MP2MP). [MEF6] uses the term Ethernet Line (E-line) to 
refer to point-to-point virtual connections, and Ethernet LAN (E-LAN) 
to refer to multipoint-to-multipoint virtual connections. [6.8011] 
also identifies point-to-multipoint (P2MP) as an area for "further 
study". Within the context of GMPLS, support is defined for point- 
to-point unidirectional and bidirectional Traffic Engineering Label 
Switched Paths (TE LSPs), see [RFC3473], and unidirectional point-to- 
multipoint TE LSPs, see [RFC4875]. 


Support for P2P and MP2MP services is defined by [G.8011] and 
required by [MEF11]. Note that while [MEF11] and [G.8011] discuss 
MP2MP, [G.8011.1] and [G.8011.2] only define support for P2P. There 
is a clear correspondence between E-Line/P2P service and GMPLS P2P TE 
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LSPs, and support for such LSPs is included in the scope of this 
document. There is no such clear correspondence between E-LAN/MP2MP 
service and GMPLS TE LSPs. Although, it is possible to emulate this 
service using multiple P2P or P2MP TE LSPs, the definition of support 
for MP2MP service is left for future study and is not addressed in 
this document. 


[MEF11] defines multiple types of control for UNI Ethernet services. 
In MEF UNI Type 1, services are configured manually. In MEF UNI Type 
2, services may be configured manually or via a link management 
interface. In MEF UNI Type 3, services may be established and 
managed via a signaling interface. From the MEF perspective, this 
document, along with [RFC6005], is aimed at the network control 
needed to support the MEF UNI Type 3 mode of operation. 


[G.8011.1], [G.8011.2], and [MEF11], together with [MEF10.1], define 
a set of service attributes that are associated with each Ethernet 
connection. Some of these attributes are based on the provisioning 
of the local physical connection and are not modifiable or selectable 
per connection. Other attributes are specific to a particular 
connection or must be consistent across the connection. The approach 
taken in this document to communicate these attributes is to exclude 
the static class of attributes from signaling. This class of 
attributes will not be explicitly discussed in this document. The 
other class of attributes is communicated via signaling and will be 
reviewed in the sections below. The major attributes that will be 
supported in signaling include: 


- Endpoint identifiers 

- Connection identifiers 

- Traffic parameters (see [RFC6003]) 
- Bundling / VLAN IDs map (EVPL only) 
-— VLAN ID Preservation (EVPL only) 


Common procedures used to support Ethernet LSPs are described in 
Section 2 of this document. Procedures related to the signaling of 
switching in support of EPL services are described in Section 3. 
Procedures related to the signaling of switching in support of EVPL 
services are described in Section 4. 


1.2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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2. Common Signaling Support 


This section describes the common mechanisms for supporting GMPLS 
signaled control of LSPs that provide Ethernet connections as defined 
in [MEF11], [G.8011.1], and [G.8011.2]. 


Except as specifically modified in this document, the procedures 
related to the processing of RSVP objects are not modified by this 
document. The relevant procedures in existing documents, such as 
[RFC3473], MUST be followed in all cases not explicitly described in 
this document. 


2.1. Ethernet Endpoint Identification 


Ethernet endpoint identifiers, as they are defined in [G.8011] and 
[MEF10.1], differ significantly from the identifiers used by GMPLS. 
Specifically, the Ethernet endpoint identifiers are character based 
as opposed to the GMPLS norm of being IP address based. 


The approach taken by this document to address this disparity 
leverages the solution used for connection identification, see 
Section 2.2 and [RFC4974], and a new CALL_ATTRIBUTES TLV defined in 
this document. The solution makes use of the [RFC4974] short Call 
ID, and supports the Ethernet endpoint identifier similar to how 
[RFC4974] supports the long Call ID. That is, the SENDER_TEMPLATE 
and SESSION objects carry IP addresses and a short Call ID, and long 
identifiers are carried in the CALL_ATTRIBUTES object. As with the 
long Call ID, the Ethernet endpoint identifier is typically only 
relevant at the ingress and egress nodes. 


As defined below, the Ethernet endpoint identifier is carried in the 
CALL_ATTRIBUTES object in a new TLV. The new TLV is referred to as 
the Endpoint ID TLV. The processing of the Endpoint ID TLV parallels 


the processing of the long Call ID in [RFC4974]. This processing 
requires the inclusion of the CALL_ATTRIBUTES object in a Notify 
message. 


2.1.1. Endpoint ID TLV 


The Endpoint ID TLV follows the Attributes TLV format defined in 
[RFC6001]. The Endpoint ID TLV has the following format: 
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+ 0 
O w 
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Endpoint ID | 


0 
0 
+-+- 
| 

+ 

| 

| 

+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type and Length fields are defined in [RFC6001]. Note that as 
defined in [RFC6001], the Length field is set to length of the whole 
TLV including the Type, Length, and Endpoint ID fields. 


Endpoint ID 


The Endpoint ID field is a variable-size field that carries an 
endpoint identifier, see [MEF10.1] and [G.8011]. This field MUST 
be null padded as defined in [RFC6001]. 


2.1.1.1. Procedures 


The use of the Endpoint ID TLV is required during Call management. 
When a Call is established or torn down per [RFC4974], a 
CALL_ATTRIBUTES object containing an Endpoint ID TLV MUST be included 
in the Notify message along with the long Call ID. 


Short Call ID processing, including those procedures related to Call 
and connection processing, is not modified by this document and MUST 
proceed according to [RFC4974]. 


2.2. Connection Identification 


Signaling for Ethernet connections follows the procedures defined in 
[RFC4974]. In particular, the Call-related mechanisms are used to 
support endpoint identification. In the context of Ethernet 
connections, a Call is only established when one or more LSPs 
(connections in [RFC4974] terms) are needed. An LSP will always be 
established within the context of a Call and, typically, only one LSP 
will be used per Call. See Section 4.4 for the case where more than 
one LSP may exist within a Call. 


2.2.1. Procedures 
Any node that supports Ethernet connections MUST be able to accept 
and process Call setups per [RFC4974]. Ethernet connections 


established according to this document MUST treat the Ethernet 
(virtual) connection identifier as the long "Call identifier (ID)", 
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described in [RFC4974]. The short Call ID MUST be used as described 
in [RFC4974]. Use of the LINK_CAPABILITY object is OPTIONAL. Both 
network-initiated and user-initiated Calls MUST be supported. 


When establishing an Ethernet connection, the initiator MUST first 
establish a Call per the procedures defined in [RFC4974]. LSP 
management, including removal and addition, then follows [RFC4974]. 
As stated in [RFC4974], once a Call is established, the initiator 
SHOULD establish at least one Ethernet LSP. Also, when the last LSP 
associated with a Call is removed, the Call SHOULD be torn down per 
the procedures in [RFC4974]. 


2.3. Traffic Parameters 


Several types of service attributes are carried in the traffic 
parameters defined in [RFC6003]. These parameters are carried in the 
FLOWSPEC and TSPEC objects as discussed in [RFC6003]. The service 
attributes that are carried are: 


- Bandwidth Profile 
- VLAN Class of Service (CoS) Preservation 
- Layer 2 Control Protocol (L2CP) Processing (see Section 2.3.1) 


Ethernet connections established according to this document MUST use 
the traffic parameters defined in [RFC6003] in the FLOWSPEC and TSPEC 
objects. Additionally, the Switching Granularity field of the 
Ethernet SENDER_TSPEC object MUST be set to zero (0). 


2.3.1. L2 Control Protocol TLV 


[MEF10.1], [G.8011.1], and [G.8011.2] define service attributes that 
impact the layer two (L2) control protocol processing at the ingress 
and egress. [RFC6003] does not define support for these service 
attributes, but does allow the attributes to be carried in a TLV. 
This section defines the L2CP TLV to carry the L2CP-processing- 
related service attributes. 


The format of the L2 Control Protocol (L2CP) TLV is as follows: 
0 1 2 3 


0L 2.34.9 06 1-8 9.0. 1.2.3.4 :5-6.7.8:-9:0: 1.2.3.4 3 617-8901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type=3 | Length=8 | 
d+ A A AO O O O O O O O O O O O O O O O O O O O O O O o A o o ho + 
| IL2CP | EL2CP | Reserved | 


AA A A A A A A A A A A A A A A A A A A A dd o + +4 
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See [RFC6003] for a description of the Type and Length fields. 
Per [RFC6003], the Type field MUST be set to three (3), and the 
Length field MUST be set to eight (8) for the L2CP TLV. 


Ingress Layer 2 Control Processing (IL2CP): 4 bits 
This field controls processing of Layer 2 Control Protocols on 
a receiving interface. Valid usage is service specific, see 


[MEF10.1], [G.8011.1], and [G.8011.2]. 


Permitted values are: 


Value Description Reference 
0 Reserved 
1 Discard/Block [MEF10.1], [G.8011.1], and [G.8011.2] 
2 Peer/Process [MEF10.1], [G.8011.1], and [G.8011.2] 
3 Pass to EVC/Pass [MEF10.1], [G.8011.1], and [G.8011.2] 
4 Peer and Pass to EVC [MEF10.1] 


Egress Layer 2 Control Processing (EL2CP): 4 bits 


s field controls processing of Layer 2 Control Protocols on a 
nsmitting interface. When MEF services are used a value of 1 MUST 
used, other valid usage is service specific, see [G.8011.1] and 
8011.2]. 


Permitted values are: 


Thi 
MUS 
by 


ue Description Reference 
Reserved 
Based on IL2CP Value [MEF 10.1] 
Generate [G.8011.1] and [G.8011.2] 
None [G.8011.1] and [G.8011.2] 
Reserved 


Reserved: 24 bits 


s field is reserved. It MUST be set to zero on transmission and 
T be ignored on receipt. This field SHOULD be passed unmodified 
transit nodes. 


Ethernet connections established according to this document MUST 


inc 
the 


lude the L2CP TLV in the [RFC6003] traffic parameters carried in 
FLOWSPEC and TSPEC objects. 
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2.4. Bundling and VLAN Identification 


The control of bundling and listing of VLAN identifiers is only 
supported for EVPL services. EVPL service specific details are 
provided in Section 4. 


3. EPL Service 


Both [MEF6] and [G.8011.1] define an Ethernet Private Line (EPL) 
service. In the words of [G.8011.1], EPL services carry "Ethernet 
characteristic information over dedicated bandwidth, point-to-point 
connections, provided by SDH, ATM, MPLS, PDH, ETY or OTH server layer 
networks". [G.8011.1] defines two types of Ethernet Private Line 
(EPL) services. Both types present a service where all data 
presented on a port is transported to the corresponding connected 
port. The types differ in that EPL type 1 service operates at the 
MAC frame layer, while EPL type 2 service operates at the line (e.g., 
8B/10B) encoding layer. [MEF6] only defines one type of EPL service, 
and it matches [G.8011.1] EPL type 1 service. Signaling for LSPs 
that support both types of EPL services are detailed below. 


Be EPL Service Parameters 


Signaling for the EPL service types only differ in the LSP Encoding 
Type used. The LSP Encoding Type used for each are: 


EPL Service LSP Encoding Type (Value) Reference 
Type 1/MEF Ethernet (2) [RFC3471] 
Type 2 Line (e.g., 8B/10B) (14) [RFC6004] 


The other LSP parameters specific to EPL Service are: 


Parameter Name (Value) Reference 
Switching Type DCSC (125) [RFC6002] 
G-PID Ethernet PHY (33) [RFC3471] [RFC4328] 


The parameters defined in this section MUST be used when establishing 
and controlling LSPs that provide EPL service type Ethernet 
switching. The procedures defined in Section 2 and the other 
procedures defined in [RFC3473] for the establishment and management 
of bidirectional LSPs MUST be followed when establishing and 
controlling LSPs that provide EPL service type Ethernet switching. 
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4. EVPL Service 


EVPL service is defined within the context of both [G.8011.2] and 
[MEF6]. EVPL service allows for multiple Ethernet connections per 
port, each of which supports a specific set of VLAN IDs. The service 
attributes identify different forms of EVPL services, e.g., bundled 
or unbundled. Independent of the different forms, LSPs supporting 
EVPL Ethernet type switching are signaled using the same mechanisms 
to communicate the one or more VLAN IDs associated with a particular 
LSP (Ethernet connection). 


The relevant [RFC3471] parameter values that MUST be used for EVPL 
connections are: 


Parameter Name (Value) Reference 
Switching Type EVPL (30) [RFC6004] 
LSP Encoding Type Ethernet (2) [RFC3471] 
G-PID Ethernet PHY (33) [RFC3471] [RFC4328] 


As with EPL, the procedures defined in Section 2 and the other 
procedures defined in [RFC3473] for the establishment and management 
of bidirectional LSPs MUST be followed when establishing and 
controlling LSPs that provide EVPL service type Ethernet switching. 


LSPs that provide EVPL service type Ethernet switching MUST use the 
EVPL Generalized Label Format per Section 4.1, and the Generalized 
Channel_Set Label Objects per [RFC6002]. A notable implication of 
bundled EVPL services and carrying multiple VLAN IDs is that a Path 
message may grow to be larger than a single (fragmented or non- 
fragmented) IP packet. The basic approach to solving this is to 
allow for multiple LSPs which are associated with a single Call, see 
Section 2.2. The specifics of this approach are describe below in 
Section 4.4. 


4.1. EVPL Generalized Label Format 


Bundled EVPL services require the use of a service-specific label, 
called the EVPL Generalized Label. For consistency, non-bundled EVPL 
services also use the same label. 


The format for the Generalized Label (Label Type value 2) used with 
EVPL services is: 
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0 al 

OF 21324 5067 7 859000: E 02 349 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Rsva | VLAN ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Reserved: 4 bits 


This field is reserved. It MUST be set to zero on transmission 
and MUST be ignored on receipt. This field SHOULD be passed 
unmodified by transit nodes. 


VLAN ID: 12 bits 
A VLAN identifier. 
4.2. Egress VLAN ID Control and VLAN ID Preservation 


When an EVPL service is not configured for both bundling and VLAN ID 
preservation, [MEF6] allows VLAN ID mapping. In particular, the 
single VLAN ID used at the incoming interface of the ingress may be 
mapped to a different VLAN ID at the outgoing interface at the egress 
UNI. Such mapping MUST be requested and signaled based on the 
explicit label control mechanism defined in [RFC3473] and clarified 
in [RFC4003]. 


When the explicit label control mechanism is not used, VLAN IDs MUST 
be preserved, i.e., not modified, across an LSP. 


4.3. Single Call - Single LSP 


For simplicity in management, a single LSP SHOULD be used for each 
EVPL type LSP whose Path and Resv messages fit within a single 
unfragmented IP packet. This allows the reuse of all standard LSP 
modification procedures. Of particular note is the modification of 
the VLAN IDs associated with the Ethernet connection. Specifically, 
[RFC6002], make-before-break procedures SHOULD be used to modify the 
Channel_Set LABEL object. 


4.4. Single Call - Multiple LSPs 


Multiple LSPs MAY be used to support an EVPL service connection. All 
such LSPs MUST be established within the same Call and follow Call- 
related procedures, see Section 2.2. The primary purpose of multiple 
LSPs is to support the case in which the related objects result in a 
Path message being larger than a single unfragmented IP packet. 
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When using multiple LSPs, all LSPs associated with the same Call/EVPL 
connection MUST be signaled with the same LSP objects with the 
exception of the SENDER_TEMPLATE, SESSION, and label-related objects. 
All such LSPs SHOULD share resources. When using multiple LSPs, VLAN 
IDs MAY be added to the EVPL connection using either a new LSP or 
make-before-break procedures, see [RFC3209]. Make-before-break 
procedures on individual LSPs SHOULD be used to remove VLAN IDs. 


To change other service parameters it is necessary to re-signal all 
LSPs associated with the Call via make-before-break procedures. 


5. IANA Considerations 
IANA has assigned new values for namespaces defined in this document 
and summarized in this section. The registries are available from 
http://www.iana.org. 


5.1. Endpoint ID Attributes TLV 


IANA has made the following assignment in the "Call Attributes TLV" 
section of the "RSVP Parameters" registry. 


Type Name Reference 
2 Endpoint ID [RFC6004] 
5.2. Line LSP Encoding 


IANA has made the following assignment in the "LSP Encoding Types" 
section of the "GMPLS Signaling Parameters" registry. 


Value Type Reference 
14 Line (e.g., 8B/10B) [RFC6004] 
5.3. Ethernet Virtual Private Line (EVPL) Switching Type 


TANA has made the following assignment in the "Switching Types" 
section of the "GMPLS Signaling Parameters" registry. 


Value Type Reference 


30 Ethernet Virtual Private Line (EVPL) [RFC6004] 


The assigned value has been reflected in IANAGmplsSwitchingTypeTC of 
the IANA-GMPLS-TC-MIB available from http://www.iana.org. 
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6. Security Considerations 


This document introduces new message object formats for use in GMPLS 
Signaling [RFC3473]. It does not introduce any new signaling 


messages, 


nor change the relationship between Label Switching Routers 


(LSRs) that are adjacent in the control plane. As such, this 
document introduces no additional security considerations to those 
discussed in [RFC3473]. 
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